DOC-7226 Move the Rust use cases to redis-rs 1.8 - #4378

… time-series-dashboard and rate-limiter use cases

The session-store and time-series-dashboard demos opened their shared connection with
Client::get_async_connection() and held it as redis::aio::Connection. That non-multiplexed
connection is gone from Client in redis-rs 1.x, and the leaderboard use case, which pins the
same 0.24 crate, already uses get_multiplexed_async_connection() and MultiplexedConnection.
Both demos and the session-store page snippet now do the same, and the rate-limiter page's
async snippet names MultiplexedConnection instead of the removed type. The change is
forward-compatible: both APIs exist in 0.24 and 1.x, so the crate pins are unchanged.

Both demos build against redis 0.24.1. The session-store demo was run against Redis 8.10.2
and passed login, session read, increment and logout. The time-series-dashboard demo writes
its samples, but its /api/snapshot endpoint returns a parse error that the unmodified demo
on main returns identically, so it is not caused by this change.

Learned: of the use cases that looked affected by redis-rs 1.x, only session-store and time-series-dashboard used the removed non-multiplexed connection in code; the others already use ConnectionManager or MultiplexedConnection
Directive: keep these demos on get_multiplexed_async_connection(), which works on the 0.24 pins and on 1.x; do not reintroduce get_async_connection()
Recheck: when the Rust use cases move to redis-rs 1.x, rerun the time-series-dashboard snapshot, which fails to parse f64 from a status reply on 0.24.1 against Redis 8.10.2
Gaps: the crate pins were not bumped, nothing was compiled against 1.x, and the prefetch-cache page still says a bare redis::aio::Connection is not Clone, which names a type that no longer exists in 1.x
Ticket: DOC-7226
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>

All 13 Rust use-case demos now depend on redis 1.8 (they pinned 0.24 or 0.27), matching the
clients/rust pages, and the use-case pages are updated to match. Compiling cleared most of it:
Value::Data, Bulk and Status became BulkString, Array and SimpleString; query_async and
invoke_async take one generic; ErrorKind::TypeError became UnexpectedReturnType and
ResponseError became Server(ServerErrorKind::ResponseError); borrowed values go through
from_redis_value_ref; scan iterators yield results; AsyncCommands needs Send + Sync.

Two changes only running the demos could find. hget takes one field in 1.x (the old one
silently sent HMGET for several), so multi-field reads use hmget. And 1.x puts a 500 ms
response timeout on every connection manager and multiplexed connection, so the job-queue
BLMOVE workers and the streaming XREADGROUP BLOCK consumers failed with "timed out" until
their managers were built with the response timeout removed.

I also fixed the time-series dashboard's as_f64 helper, which already failed on main against
a current server: RESP2 time series doubles arrive as simple strings and the helper only
accepted integers and bulk strings.

Every demo was built and run against Redis 8.10.2 and exercised through its HTTP endpoints,
including the two candle-based demos with the cached MiniLM model. The pages now state the
Rust 1.88 minimum that redis 1.8 requires, and the prefetch-cache page no longer describes the
removed non-multiplexed connection. Bugbot and review have not seen this commit yet.

Learned: redis-rs 1.x applies a 500 ms response timeout to every ConnectionManager and multiplexed connection, so blocking commands such as BLMOVE and XREADGROUP BLOCK fail with "timed out" at runtime while the code still compiles
Constraint: demos that block on the server (job-queue, streaming) must build their ConnectionManager with ConnectionManagerConfig::new().set_response_timeout(None)
Directive: use hmget for several hash fields; hget takes exactly one field in redis-rs 1.x
Recheck: the crate is declared as 1.8 and needs Rust 1.88; if the pages' stated Rust minimum or the redis version changes, update all 13 pages together
Gaps: nothing was tested against redis 1.0.4 to 1.7, the page snippets were edited to mirror the .rs files but not compiled, and the demos were not run against a cluster or Sentinel
Ticket: DOC-7226
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>

count_entities looped over the scan iterator with while let Some(_k) and never looked at the
item. In redis-rs 1.x next_item yields Option<RedisResult<T>>, so a SCAN error was counted as
an entity and never returned. Bugbot caught it. The compiler could not, because a pattern that
discards the item type-checks under both versions. The loop now propagates the error, like the
other two scan loops in the file.

Checked every other next_item loop in the Rust use cases; the only other two (prefetch-cache)
already propagate the error. The feature-store demo still reports 200 entities.

Learned: after a redis-rs 1.x bump, a loop that discards the item (while let Some(_k) = iter.next_item()) compiles unchanged but silently counts scan errors as items, so grep every next_item loop instead of relying on compiler errors
Ticket: DOC-7226
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>